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ABSTRACT 

The Experiment Control System II (ECS-II®) is designed to make available to the microgravity 
research community the same tools and mode of automated experimentation that their ground-based 
counterparts have enjoyed for the last two decades. The design goal was accomplished by combining 
commercial automation tools familiar to the experimenter community with system control components 
that interface with the on-orbit platform in a distributed architecture. The architecture insulates the 
experimenter from the details of the on-orbit platform while providing the payload engineer with the 
tools necessary for managing a payload. By using commercial software and hardware components 
whenever possible, development costs were greatly reduced when compared to traditional space 
development projects. Using commercial-off-the-shelf (COTS) components also improved the usability 
of the system by providing familiar user interfaces, providing a wealth of readily available 
documentation, and reducing the need for training on system-specific details. The modularity of the 
distributed architecture makes it very amenable for modification to different on-orbit experiments 
requiring robotics-based automation. 

INTRODUCTION 

Advanced Modular Power Systems, Inc. (AMPS), a small business, was incorporated in 1990 to 
conduct R&D and product development of advanced, efficient, cost-effective and reliable energy 
conversion systems for the production of electrical power in space and terrestrial applications. 

Similarly, the Space Resources Division(AMPS-SR) concentrates on the research, development, 
integration and manufacturing of cost-effective instruments, experiments, and complete 
systems(payloads) for terrestrial markets and space missions. 

AMPS-SR objectives are the creation of a space automation supplier to industry. This industry is 
defined to include suppliers of laboratory automation equipment such as sample preparation and 
manipulation, sensors, process control, data acquisition and control, and data analysis systems. 
Technological and economic elements of these industries are well established, with suppliers providing 
automation-related products and services to terrestrial "customer" industries including electronic, 
pharmaceutical, chemical, and other consumer product areas (i.e., food and beverage). Many of these 
same industries, particularly those in the electronic and pharmaceutical areas, also have an active 
research and development (R&D) interest in the unique properties of the space environment 
(microgravity, ultrahigh vacuum, view of earth, etc.). 

Recognizing the commercial potential of space-based experimentation and discovery as well as 
manufacturing, AMPS-SR is involved in several joint project activities with both public and private 
partners. While these projects focus on different niches, they all have a common goal to reduce the cost 
of space-based research and manufacturing through the development and deployment of technology 
that extends established terrestrial laboratory automation techniques to the space environment. 

This paper examines the system architecture of the Experiment Control System (ECS), as used in 
the Robot Operated Materials Processing System (ROMPS), and its evolution into the private sector 
product the ECS-II, which will be used on Wake Shield Facility 3rd flight (WSF-3) as the control 
system for the Automated Wafer Cartridge System (AWCS). The ECS and ECS-II systems are built 
around two commercial off-the-shelf (COTS) technologies, Zymark's Zymate System V Controller and 
Interface and Control Systems' (ICS) Spacecraft Command Language (SCL). 
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Other ECS-2 missions include, the enhanced ROMPS-2, the large scale manufacturing mission on 
WSF-4, and a joint JPL-AMPS INSTEP payload that will demonstrate essential AMTEC power 
conversion technology for the Pluto Express program. 

ROMPS MISSION OVERVIEW 


In 1991 a request was made by NASA's Goddard Space Flight Center (GSFC) to propose an 
alternative Experiment Control System (ECS) design for the ROMPS project. The ROMPS project is a 
Space Shuttle Hitchhiker mission centered around the rapid thermal processing (RTP) of semiconductor 
materials. The ROMPS mission's short-term objective is to develop commercially promising in-space 
processes by using a robot-based automation system to lower the cost of the material procedures. Figure 



ROMPS AUTOMATED RAPID THERMAL PROCESSING 

Rapid thermal processing is a widely used industrial material processing procedure for two- 
dimensional semiconductor materials. In this process, a heat source capable of producing uniform 
surface area temperatures (usually a quartz halogen lamp) is used to melt semiconductor materials. The 
semiconductor materials are then allowed to cool and recrystallize. Semiconductor materials 
recrystallized in micro-gravity have larger and more uniform crystals that have better electrical 
properties. 

ROMPS provides a robotic-based system capable of automating the RTP with up to 155 samples. In 
this system, a custom-built halogen lamp furnace provides the heat source for the RTP of the samples. 
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A robot designed by GSFC moves the semiconductor samples between their storage racks and the 
furnace. The ECS was developed to provide the computer, computer software, and electrical sub- 
systems for automatically controlling and monitoring the RTP of the semiconductor materials. 

WSF-3/AWCS MISSION OVERVIEW 


Carried into space in the payload 
bay of the Space Shuttle, the Wake 
Shield Facility (WSF) presents a 
unique platform for the 
development of advanced 
semiconductor materials and devices 
through the use of the ultra-vacuum 
of space. The WSF is released into 
orbit by the Shuttle RMS robot arm. 

After the WSF maneuvers away 
from the Shuttle, it orients itself to 
shield out the residual atmosphere 
that remains in low earth orbit, 
thereby creating an ultra-pure 
vacuum in its wake, see Figure 2. 

This ultra-vacuum, nearly empty of all molecules, is then used to conduct a series of thin film growths 
by a process called molecular beam epitaxy (MBE) which produces exceptionally pure and atomically 
ordered thin films of semiconductor compounds such as gallium arsenide. Using this process, the WSF 
offers the potential of producing the next generation of semiconductor and superconductor thin film 
materials, and the devices they will make possible. After a several day period of free flight, the WSF 
platform is retrieved by the Space Shuttle and returned to Earth. 

The first AWCS was designed to provide the WSF with a prototype manufacturing facility. In its 
current configuration , it will transport 100+ wafers to and from orbit, an increase of 15 times the present 
number of wafers processed. The AWCS design is readily scaleable to 1000+ wafers required by the 
WSF-4 mission. The AWCS utilizes a unique, patented 2 degree-of-freedom(dof) robot arm/gripper to 
move the wafers from the storage racks to the substrate rotator. The present system is designed to mount 
directly to the existing WSF carousel flange and to conform to ultra-high vacuum (UHV) practices 
regarding materials and mechanical 
systems. 

WSF-3/AWCS MBE PROCESSING 

Epitaxy, a technique for controlled 
deposition of thin films in a vacuum, is 
the atomically ordered growth of a 
material on a substrate in an atom-by- 
atom, atomic-layer-by-atomic-layer 
manner. SVEC employs an epitaxial 
technique known as molecular beam 
epitaxy (MBE), whereby atoms or 
molecules emitted from heated 
crucibles impinge upon a substrate, 
condensing and forming a thin film, see 
Figure 3. The better the vacuum 



Figure 3 - MBE Processing 



Figure 2 - Deployed Wake Shield Facility 
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quality, the higher the quality of the thin film material grown. Scientists consider this technique to be 
one of the most powerful methods for synthesizing new and improved materials and devices. 


Table 1-Mission Requirements Matrix, provides a matrix of the mission requirements for both the 
ROMPS and WSF-3/ AWCS missions. Also, included are the requirements for other upcoming missions. 


TABLE 1 - MISSION REQUIREMENTS MATRIX 



FUNCTIONAL REQUIREMENTS 


Robot Requirements 


Motion Control Of N-Dof Robot 
Mechanisms 


End-Of-Travel (Eot) And Over-Force 
(Oyf) 


Calibration Of Home Position 


Stored Robot Move Sequences 




Furnace Controller 


Power Or Temperature Setpoint 


Timed On/Off 


Multi-Step Time-Temperature Profiles 


Process Sensors 


Thermocouples, Thermistors 


Video-Microsco 


Non-Contact Temperature Measurement 


Reflected High Energy Electron 
Diffraction 


Process Control 


Closed Loop Temperature Control 


Machine Vision Inspection Of Crystal 
Grain Boundaries 


Payload Controller 


Science /Engineering Data Collection And 
Transmission 


Support Of Carrier CC&T Interfaces 


Scripted Control Of Process Steps 


Automated Health And Safet 


Non-Volatile Storage Of In-Flight 
Mission Changes 


Ground Station 


Archiving/ Playback Of Telemetr 


Command Generation 


Display And Analysis Of 
Science /Engineering Data 


Support NASA/ Commercial Ground 
Station Interfaces 


Configuration Control 


Distribution Of Telemetry Via Internet 


ROMPS WSF-3 


ROMPS-2 


WSF-4 




AMTEC 


X 

X 
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ECS/ECS-II DISTRIBUTED SYSTEM ARCHITECTURE 


The decision to use a distributed system architecture constructed of COTS components was driven by 
factors including: 

• low cost 

• use of commercial software packages 

• 100% compatibility of software between ground development and flight systems 

• parallel development capability on non-flight ground system 

• established set of development tools 

Both the ECS and ECS-II are designed using the same overall system architecture. The major 
difference is the use of COTS hardware to implement the servo subsystem in the ECS-II. Figure 4 shows 
the migration from the terrestrial architecture to the ECS/ROMPS architecture, then to the ECS-II/ 
AWCS architecture. 

USE OF COTS SINGLE-BOARD COMPUTERS AND PERIPHERALS 

First and foremost to meet our commercial customer objectives, the use of COTS components reduces 
the cost of experimental systems. Second, COTS components accelerate the space investigator's access to 
familiar or state-of-the-art technology. 

Reduced Cost 

While it is difficult to compare the cost of conventional space "qualified" systems with space 
"ruggedized" systems, the following comparisons are of interest: 

• An accepted estimate of developing full space qualified avionics systems (with the same mass as 
the ECS) ranges from $1.1M to 7.6M.3 

• Our approach, maximizing COTS content and accepting system reliability estimates of 97 percent 
versus 99.99 percent, reduced the actual cost (including mission support) to $750K for ROMPS. 

Acceleration of Technology Introduction 

As shown in Table 2, the introduction of computers to space missions has significantly lagged 
behind the same technology's commercial introduction. While a significant element of the lag is the 
lengthy and costly delay associated with radiation hardening, there are many missions that do not 
require this characteristic. One of our goals is to accelerate the introduction of a new computing 
capability where the need for high performance at low cost outweighs susceptibility to radiation. 

In the upgrade of the ECS to the ECS-II one COTS module, a DSP based servo controller, allowed the 
replacement of three custom modules. This change increased the servo loop rate by a factor of 80, and 
also allows the use of both stepper and servo motors. 
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Figure 4. Migration of Terrestrial Architecture to a Space-Hardened Architecture 
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Overforce 
Shutdown Line 



Table 2. Technology Introduction Acceleration 


Computer Technology 

Commercial 

Introduction 

Space Mission 
Launch 

Delay in Years 

X186/188 also PC-XT 

1983 

1989 

6 

x286 also PC- AT 

1984 

1989 est 

5 

x386 

1988 

1993 est 

5 

x486 

1989 

1995 est 

6 

Pentium 

1993 

1996 est 

3 

PowerPC 

1994 

1996 est 

2 

R6000 

1995 

1996 est 

1 


Ra p idly increa sin g COTS C onte n t 

In less than three years, we have gone from systems with no COTS content to systems with better 
than 60 percent COTS content (see Table 3). In 1992 we achieved 50 percent COTS contents; by 1996 we 
are planning systems with 80 percent COTS content. With each new customer and program, we continue 
to reduce the custom content of our systems while we improve performance. 


Table 3. COTS Content Increase 



ARD 

ROMPS 

AWCS 

ROMPS-2 


1992 

1994 

1996 

1997 

Custom modules 

4 

4 

2 

2 * 

COTS modules 

4 

6 

9 

7 

% COTS content 

50% 

60% 

81% 

78% 


*Both custom modules are reused designs. 


THE FLIGHT SEGMENT ARCHITECTURE 

Figures 5 and 6 summarize the mapping of functional requirements onto the flight subsystems of the 
ECS and ECS-II systems. These figures also reveal the hierarchical levels of experiment control 
performed by the different subsystems. Moving from the SCL Experiment Supervisor on the far left to 
the Robot Servo Controller on the far right, the command interfaces become less abstract and more 
device-specific. 

At the SCL Experiment Supervisor, the control of the experiment is at a very high abstraction 
level. This subsystem monitors the health and safety of the payload and halts the automation scripts 
if it detects an anomalous condition, such as temperature, of the motor drivers exceeding the safe 
operating limit. 

During the ROMPS mission this subsystem executed the RTP processing scripts, which set sample 
processing parameters and initiated laboratory unit operations by sending commands to the Zymate 
System V Controller. 

During the WSF-3/AWCS mission this subsystem will execute the Substrate Transfer scripts, 
which moves a specific wafer between its storage station, the rotator, a cooling station, and finally 
back to its storage station. 

In both cases, the Zymate System V Controller executes the steps of the laboratory unit operations 
initiated by the SCL Experiment Supervisor. Device-specific commands are sent to the Robot Servo 
Controller to complete these laboratory unit operations. 
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Figure 5 - Requirements Mapping of ROMPS Flight Subsystems 
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Figure 6 - Requirements Mapping of AWCS Flight Subsystems 
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Many of the disadvantages of a distributed architecture are eliminated in this system by the use of 
simple, robust, and well-tested communication protocols. 


THE GROUND SEGMENT ARCHITECTURE 


The ground station architecture also makes use of a distributed architecture. Figure 7 summarizes 
the mapping of functional requirements onto the ground station subsystems of the Experiment Control 
System. Again, the hierarchical levels of command and control are shown. Decreasing levels of 
experiment control abstraction are shown as one proceeds from left to right across this figure. 


SCL 


Telemetry 


To CCGSE 



Experimenter Schedul ^Processing 
Change Interface 

Display Experiment Date 

Hard Copy Report of Experiment 
Data 


Man Machine Command /Telemetry 
Interface to Payload 

Starts top Scripted Processing 
Procedu res 

Query of Standard Telemetry Data 


Graphical Display of Telemefy Data 
Audible and Visual Alarm Indicators 


Custom Carrier Ground Support 
Equipment tot erf ace 

Display of ASCI Text Message Data 

Archiving'Playback of Telemetered 
Data 


Ground Tracking of Experiment 
a nd Schedul e Ch ang es 


Figure 7. Requirement Mapping of Ground Station Subsystems 

At the far left, the Experiment Display Console allows the primary investigators to extract 
specific data from archived telemetry, allowing creation of reports. Additionally, the primary 
investigators use a set of spreadsheets to generate updated scripts to be executed against the on-board 
sample processing and schedule parameters. These updated scripts are then sent to the payload 
operator for preparation for upload to the payload. 

The SCL Command Console is used by the payload operator to command the payload. Commands 
are processed by the SCL Command Console's compiler and transmitted to the Data I/O Console for 
upload to the payload. The SCL Command Console is also responsible for running ground side rules and 
scripts. 

The Telemetry Display Console is a graphical display of the incoming telemetry. This graphical 
display is done using Lab View®, see Figure 8 & Figure 9. The items being displayed are easily changed 
by opening another LabView Virtual Instrument® (VI). This allows an easy method to switch between 
engineering and science data displays. It is also possible to have more than one Telemetry Display 
Console. 

At the Data Input/Output (I/O) Console, incoming telemetry from the payload is archived, and 
changed telemetry items are broadcast on the network for the other consoles. The Data I/O Console is 
also responsible for archiving incoming telemetry data, displaying text messages from the payload, 
and uploading the compiled command data sent from the attached SCL Command Console. 

The Telemetry Display Console and the SCL Command Consoles receive updates for their local 
telemetry databases across the Ethernet network. These data are placed on the Ethernet network by 
the Data I/O Console. 
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Figure 8 - Robot Telemetry LabView® Display 
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- Payload Processor Health LabView® Display 





All of the application programs that make up the ground station use the standard Macintosh 
window/icon/pointer/mouse user interface paradigm. This allows users to concentrate on learning the 
functionality of the applications without worrying about the details of the human-machine interface. 

MISSION OPERATIONS FOR MATERIAL PROCESSING PROCEDURES 


One of the driving philosophies of the ECS/ECS-II system architecture is to enable the Pis to 
interact with the payload in a meaningful way without the need of a payload operator to translate 
every command request into a set of payload directives. To meet this requirement, it was necessary to 
identify the operations the Pis would be interested in initiating and the telemetry data that would be 
of immediate value to them during mission operations. To accommodate this method of command and 
control, a set of on-board SCL mission scripts was implemented that would take as an input a list of 
samples to be processed. These scripts would then access a global table containing the processing 
parameters for all the samples aboard the payload. 

To enable the Pis to interact with the payload, it was necessary to provide them with a data-entry 
mechanism for specifying a list of samples to be processed, and the processing parameters for these 
samples. It was decided that because this data was essentially tabular in nature, a spreadsheet could 
be used as the data input mechanism. Custom spreadsheet macros allow the user to generate lists of 
samples to be processed and to specify processing parameters. These macros create ASCII files to be 
compiled by SCL into scripts, which are uploaded and executed by the payload operator. 

The ROMPS mission required that the Pi's be able to specify up to seven time/ temperature profiles 
for each sample. Additional, the Pi's were able to specify which samples were to be processed during 
an operational period. 

The upcoming WSF/AWCS missions contain very different requirements. The WSF3/AWCS 
mission is simpler than that of the ROMPS mission. During this mission SCL controls only the transfer 
of single substrates since all processing is controlled by the Pi's on the ground. The Pi's will indicate 
which substrate they want and the operator will execute the Substrate Transfer script using the 
substrate number as an argument. 

It is expected that the WSF-4/AWCS mission requirements will be much more demanding. All 
factors of the MBE processing cycle will be controlled by the ECS-2. This includes substrate transfer, 
substrate heating, source cell heating, source cell shutter control and RHEED processing. SCL will be 
used for overall process control through the use of its script and rules. The RHEED processing will be 
done by a dedicated vision processing engine, which along with other sensors will provide SCL with 
the information needed to process the substrate. The Pi’s will again use a spreadsheet to enter the 
information regarding the process parameters. 

POST-MISSION DATA ANALYSIS 

During the mission, data are archived by the DatalO application running on the data I/O console 
into playback files. These playback files archive the incoming telemetry packets and the outgoing 
command packets. The DatalO application can replay these play-back files and will drive all the 
attached processes as if the data were coming in real time. This allows the LabView application 
running on the Experiment Display Console to display archived data in order to review mission events. 
When playing back archive file, DatalO can preserve the relative time domain in which the 
telemetry occurred or at the maximum speed that the system is capable of performing. 

In addition to the ability to drive attached telemetry display applications, the DatalO 
application can produce spreadsheet importable text files containing selected telemetry items. DatalO 
performs the necessary data translations so the telemetry items are presented in user units. 
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CONCLUSION 


The ECS for the ROMPS payload was completed in just 13 months with delivery of over 30,000 lines 
of source code, three space-hardened computer systems, and the electrical harnessing to connect them. 
The staffing of this project included two full-time software engineers, two software contractors, one full- 
time electrical engineer, one part-time mechanical engineer, one part-time assembly technician, and 
three co-op students. ROMPS flew on STS-64 where it successfully accomplished all of the primary and 
secondary objectives, well ahead of the mission schedule. The high level scripting and expert rule 
evaluation capability of the ECS was the key to achieving the early completion of all mission 
objectives. 

AMPS has invested in the productization of the ECS and is offering the ECS-II system for sale as 
the first affordable off-the-shelf option for low cost missions. Ideal applications include the 
Hitchhiker and INSTEP programs. 

AMPS-SR's ongoing challenge is to adapt the ECS-II to automate the MBE processing methods that 
will be performed by ground operators on WSF-3. This mission will extend the capabilities of the ECS 
with the addition of process control and process sensors. Keeping with the COTS philosophy, and 
modular architecture, this set of new capabilities will include pre-integrated add-on modules that 
perform real-time machine vision and indirect temperature sensing for the purpose of in-line process 
control. 

All low earth orbit researchers can benefit from simple control of their experiments and faster turn- 
around of mission data. 
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